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Abstract 
This document defines two RTP Control Protocol (RTCP) Extended Report 
(XR) blocks that allow the reporting of initial synchronization delay 
and synchronization offset metrics for use in a range of RTP 
applications. 
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Appendix A. Metrics Represented Using the Template from RFC 6390 ..12 
1. Introduction 
1.1. Synchronization Delay and Offset Metrics Reporting Blocks 


This document defines two new block types to augment those defined in 
[RFC3611], for use in a range of RTP applications. 


The first new block type supports reporting of the Initial 
Synchronization Delay to establish a multimedia session. Information 
is recorded about the time difference between the start of RTP 
sessions and the time the RTP receiver acquires all components of RTP 
sessions in the multimedia session [RFC6051]. 


The second new block type supports reporting of the relative 
synchronization offset time of two arbitrary streams (e.g., between 
audio and video streams), with the same RTCP CNAME included in RTCP 
Source description items (SDES) packets [RFC3550]. 


These metrics belong to the class of transport-level metrics defined 
in [RFC6792]. 
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1.2.  RTCP and RTCP XR Reports 


The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 
defined an extensible structure for reporting -- the RTCP Extended 
Report (XR). This document defines a new Extended Report block for 
use with [RFC3550] and [RFC3611]. 


1.3. Performance Metrics Framework 


"Guidelines for Considering New Performance Metric Development" 
[RFC6390] provides guidance on the definition and specification of 
performance metrics. "Guidelines for Use of the RTP Monitoring 
Framework" [RFC6792] provides guidance for reporting block format 
using RTCP XR. The metrics block described in this document is in 
accordance with the guidelines in [RFC6390] and [RFC6792]. 


1.4. Applicability 


When joining each session in layered video sessions [RFC6190] or the 
multimedia session, a receiver may not synchronize playout across the 
multimedia session or layered video session until RTCP Sender Report 
(SR) packets have been received on all components of RTP sessions. 
The components of RTP sessions are per-media-type RTP sessions for 
the multimedia sessions or per-layer RIP sessions for the layered 
video sessions. For multicast sessions, the Initial Synchronization 
Delay metric varies with the session bandwidth, the number of 
members, and the number of senders in the session. The RTP Flow 
Initial Synchronization Delay Metrics Block defined in this document 
can be used to report such a metric, i.e., the Initial 
Synchronization Delay to receive all the RTP streams belonging to the 
same multimedia session or layered video session. In the absence of 
packet loss, the Initial Synchronization Delay is equal to the 
average time taken to receive the first RTCP packet in the RTP 
session with the longest RTCP reporting interval. In the presence of 
packet loss, the media synchronization should rely on the in-band 
mapping of RTP and NTP-format timestamps [RFC6051] or wait until the 
reporting interval has passed, and the next RTCP SR packet is sent. 


Receivers of the RTP Flow Initial Synchronization Delay Metrics Block 
could use this metric to compare with targets (i.e., Service Level 
Agreement or thresholds of the system) to help ensure the quality of 
real-time application performance. 


In an RTP multimedia session, there can be an arbitrary number of 
Streams carried in different RTP sessions, with the same RTCP CNAME. 
These streams may be not synchronized with each other. For example, 
one audio stream and one video stream belong to the same session, and 
the audio stream is transmitted lagging behind the video stream for 
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multiple tens of milliseconds [TR-126]. The RIP Flow Synchronization 
Offset block can be used to report such synchronization offset 
between video and audio streams. This block is also applied to the 


case where an RTP session can contain media streams with media from 
multiple media types. The metrics defined in the RTP Flow 
Synchronization Offset Metrics Block can be used by the network 
manager for troubleshooting and dealing with user-experience issues. 


2. Terminology 
2.1. Standards Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


In addition, the following terms are defined: 
Initial Synchronization Delay: 


A multimedia session comprises a set of concurrent RTP sessions 
among a common group of participants, using one RTP session for 
each media type. The Initial Synchronization Delay is the average 
time for the receiver to synchronize all components of a 
multimedia session [RFC6051]. 


Synchronization Offset: 


Synchronization between two media streams must be maintained to 
ensure satisfactory Quality of Experience (QoE). Two media 
Streams can be of the same or different media types belonging to 
one RTP session, or of different media types belonging to one 
multimedia session. The Synchronization Offset is the relative 
time difference of the two media streams that need to be 
synchronized. 


3. RTP Flow Initial Synchronization Delay Metrics Block 


This block is sent by RTP receivers and reports the Initial 
Synchronization Delay beyond the information carried in the standard 
RTCP packet format. Information is recorded about the time 
difference between the start of the multimedia session and the time 
when the RTP receiver acquires all components of RTP sessions 
[RFC6051] measured at the receiving end of the RTP stream. 


This block needs to be exchanged only occasionally, for example, sent 
once at the start of the RTP session. 
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3.1. Metric Block Structure 


The RTP Flow Initial Synchronization Delay Metrics Block has the 
following format: 


0 I 2 3 

0 12.3 4 5.6 85: 9 0 L2 342560 7:589 0 LZ34256- T8 9-0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| BT=27 | Reserved | Block length=2 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SSRC of Source | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Initial Synchronization Delay 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: Report Block Structure 


3.2. Definition of Fields in RTP Flow Initial Synchronization Delay 
Metrics Block 


Block type (BT): 8 bits 


The RTP Flow Initial Synchronization Delay Metrics Block is 
identified by the constant 27. 


Reserved: 8 bits 
This field is reserved for future definition. In the absence of 
such a definition, the bits in this field MUST be set to zero and 
ignored by the receiver. 


Block length: 16 bits 


The constant 2, in accordance with the definition of this field in 
Section 3 of RFC 3611 [RFC3611]. 


SSRC of source: 32 bits 
The SSRC of the media source SHALL be set to the value of the SSRC 
identifier carried in any arbitrary component of RTP sessions 
belonging to the same multimedia session. 

Initial Synchronization Delay: 32 bits 
The average delay, expressed in units of 1/65536 seconds, from the 
beginning of the multimedia session [RFC6051] to the time when 


RTCP packets are received on all of the component RTP sessions. 
It is recommended that the beginning of the multimedia session is 
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4. 


chosen as the time when the receiver has joined the first RTP 
session of the multimedia session. The value of the Initial 
Synchronization Delay is calculated based on received RICP SR 
packets or the RTP header extension containing the in-band mapping 
of RTP and NTP-format timestamps [RFC6051]. If there is no packet 
loss, the Initial Synchronization Delay is expected to be equal to 
the average time taken to receive the first RTCP packet in the RTP 
session with the longest RTCP reporting interval or to the average 
time taken to receive the first RTP header extension containing 
the in-band mapping of RTP and NTP-format timestamps. 


If the measurement is unavailable, the value of this field with 
all bits set to 1 MUST be reported. 


RTP Flow Synchronization Offset Metrics Block 


In the RTP multimedia sessions or one RTP session, there can be an 
arbitrary number of media streams and each media stream (e.g., audio 
Stream or video stream) is sent in a separate RTP stream. In case of 
one RTP session, each media stream or each medium uses a different 
SSRC. The receiver correlates these media streams that need to be 
synchronized by means of the RTCP CNAME contained in the RTCP Source 
Description (SDES) packets [RFC3550]. 


This block is sent by RTP receivers and reports the synchronization 
offset of two arbitrary RTP streams that need to be synchronized in 
the RTP multimedia session. Information is recorded about the 
relative average time difference between two arbitrary RTP streams 
(the reporting stream and the reference stream) with the same CNAME 
and measured at the receiving end of the RTP stream. In order to 
tell what the offset of the reporting stream is relative to, the 
block for the reference stream with synchronization offset of zero 
should be reported. 


Instances of this block refer by synchronization source (SSRC) to the 
Separate auxiliary Measurement Information block [RFC6776], which 
describes measurement periods in use (see Section 4.2 of [RFC6776]). 
This metrics block relies on the measurement period in the 
Measurement Information block indicating the span of the report and 
SHOULD be sent in the same compound RTCP packet as the Measurement 
Information Block. If the measurement period is not received in the 
same compound RTCP packet as this block, this block MUST be 
discarded. 
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4.1. Metric Block Structure 


The RIP Flow General Synchronization Offset Metrics Block has the 
following format: 


0 I 2 3 
Q L2 3 e S 282 1D: CA 2. :3* 4 -5- OP Be OF de E S e e KA X 
+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| BT=28 | | Reserved | Block length=3 
+-+-+-+-+-+-+-+-+-+-+- +++ 
| SSRC of source | 
+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Synchronization Offset, most significant word 
AA AA KA KA KA SA AA AAA AA MAA SAA SA KA KA WA NA AA WAA WAA SA WA KA KA KA AA AA KA WA KA AWA 
| Synchronization Offset, least significant word | 
+-+-+-+-+-+-+-+-+-+-+- +++ 


Figure 2: Report Block Structure 


4.2. Definition of Fields in RTP Flow General Synchronization Offset 
Metrics Block 


Block type (BT): 8 bits 


The RTP Flow General Synchronization Offset Metrics Block is 
identified by the constant 28. 


Interval Metric Flag (I): 2 bits 


This field is used to indicate whether the Burst/Gap Discard 
Summary Statistics metrics are Sampled, Interval, or Cumulative 
metrics: 


I=10: Interval Duration - the reported value applies to the 
most recent measurement interval duration between 
successive metrics reports. 

I=11: Cumulative Duration - the reported value applies to the 
accumulation period characteristic of cumulative 
measurements. 

I=01: Sampled Value - the reported value is a sampled 
instantaneous value. 


In this document, the value I=00 is the reserved value and MUST 


NOT be used. If the value I=00 is received, then the XR block 
MUST be ignored by the receiver. 
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Reserved: 6 bits 


This field is reserved for future definition. In the absence of 
such a definition, the bits in this field MUST be set to zero and 
MUST be ignored by the receiver. 


Block length: 16 bits 


The constant 3, in accordance with the definition of this field in 
Section 3 of RFC 3611 [RFC3611]. 


SSRC of Source: 32 bits 


The SSRC of the media source SHALL be set to the value of the SSRC 
identifier of the reporting RIP stream to which the XR relates. 


Synchronization Offset: 64 bits 


The synchronization offset of the reporting RIP stream relative to 
the reference stream with the same CNAME. The calculation of 
Synchronization Offset is similar to the Difference D calculation 
in the RFC 3550. That is to say, if Si is the NTP timestamp from 
the reporting RIP packet i, Ri is the time of arrival in NTP 
timestamp units for reporting RTP packet i, Sj is the NTP 
timestamp from the reference RTP packet j, and Rj is the time of 
arrival in NTP timestamp units for reference RTP packet j, then 
the value of the Synchronization Offset D may be expressed as 


D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj- Sj) - (Ri - Si) 


If in-band delivery of NTP-format timestamps is supported 
[RFC6051], Si and Sj should be obtained directly from the RTP 
packets where NIP timestamps are available. If not, Si and Sj 
should be calculated from their corresponding RTP timestamps. The 
value of the Synchronization Offset is represented using a 64-bit 
signed NTP-format timestamp as defined in [RFC5905], which is a 
64-bit signed fixed-point number with the integer part in the 
first 32 bits and the fractional part in the last 32 bits. A 
positive value of the Synchronization Offset means that the 
reporting stream leads before the reference stream, while a 
negative one means the reporting stream lags behind the reference 
stream. The Synchronization Offset of zero means the stream is 
the reference stream. 


If the measurement is unavailable, the value of this field with 
all bits set to 1 MUST be reported. 
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5. SDP Signaling 


[RFC3611] defines the use of SDP (Session Description Protocol) 
[RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 
without prior signaling. 


5.1. SDP rtcp-xr-attrib Attribute Extension 


Using the Augmented Backus-Naur Form (ABNF) [RFC5234], two new 
parameters are defined for the two report blocks defined in this 
document to be used with SDP [RFC4566]. They have the following 
syntax within the "rtcp-xr" attribute [RFC3611]: 


xr-format =/ xr-rfisd-block 
/ xr-rfso-block 


xr-rfisd-block = "rtp-flow-init-syn-delay" 
xr-rfso-block = "rtp-flow-syn-offset" 


Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 
and the full syntax of the "rtcp-xr" attribute. 


5.2. Offer/Answer Usage 


When SDP is used in the offer/answer context, the SDP Offer/Answer 
usage defined in [RFC3611] applies. 


6. IANA Considerations 
New report block types for RTCP XR are subject to IANA registration. 
For general guidelines on IANA allocations for RTCP XR, refer to 


Section 6.2 of [RFC3611]. 


This document assigns two new block type values in the RTCP XR Block 
Type Registry: 


Name: RFISD 

Long Name: RTP Flow Initial Synchronization Delay 
Value 27 

Reference: Section 3 

Name: RFSO 

Long Name: RTP Flow Synchronization Offset 

Value 28 

Reference: Section 4 
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This document also registers two new SDP [RFC4566] parameters for the 
"rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 


* "rtp-flow-init-syn-delay " 
* "rtp-flow-syn-offset" 


The contact information for the registrations is: 
RAI Area Directors <rai-ads@tools.ietf.org> 


7. Security Considerations 


When using Secure RTP [RFC3711], or other media-layer security, 
reporting accurate synchronization offset information can expose some 
details about the timing of the cryptographic operations that are 
used to protect the media. There is a possibility that this timing 
information might enable a side-channel attack on the encryption. For 
environments where this attack is a concern, implementations need to 
take care to ensure cryptographic processing and media compression 
take the same amount of time irrespective of the media content, to 
avoid the potential attack. 


Besides this, it is believed that this RTCP XR block introduces no 
new security considerations beyond those described in [RFC3611]. 
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Appendix A. 


a. 


Asaeda, 


Initial Synchronization Delay Metric 
* Metric Name: RTP Initial Synchronization Delay 


* Metric Description: See the definition of "Initial 
Synchronization Delay" in Section 2.1. 


May 2014 


Metrics Represented Using the Template from RFC 6390 


* Method of Measurement or Calculation: See the definition of 


the "Initial Synchronization Delay" field in Section 3.2. 


* Units of Measurement: See the definition of the "Initial 


Synchronization Delay" field in Section 3.2. 


* Measurement Point(s) with Potential Measurement Domain: See 


the first paragraph of Section 3. 


* Measurement Timing: See the second paragraph of Section 3. 


* Use and applications: See Section 1.4. 
* Reporting model: See RFC 3611. 
Synchronization Offset Metric 


* Metric Name: RTP Synchronization Offset Delay 


* Metric Description: See the definition of "Synchronization 


Offset" in Section 1.2. 


* Method of Measurement or Calculation: See the definition of 


the "Synchronization Offset" field in Section 4.2. 


* Units of Measurement: See the definition of the 
"Synchronization Offset" field in Section 4.2. 


* Measurement Point(s) with Potential Measurement Domain: See 


the second paragraph of Section 4. 


* Measurement Timing: See the third paragraph of Section 4.2 for 


measurement timing and the Interval Metric flag. 
* Use and applications: See Section 1.4. 


* Reporting model: See RFC 3611. 
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